home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP030192.ARJ / 03-01-92.TPC
Text File  |  1992-03-01  |  56KB  |  1,545 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       02-23-92 01:59:40
  6. From       Trevor Carlsen
  7. To         Harald Harms
  8. Subject    Text File Snag
  9.  
  10.  TCID:ca5044b3 5b15
  11. >   while not eof(f) do begin
  12. >     len := 0;
  13. >     while (not eoln(f)) and (len < 255) do begin
  14. >       inc(len);
  15. >       read(f,inpstr[len]);
  16. >     end;  { while (not eoln(f))... }
  17. >     if eoln(f) then
  18. >       readln(f);
  19. >     Do what you want with the string here.
  20. >   end; { while not eof(f) }
  21.  
  22. HH> What is so wrong with:
  23. HH> var t: text;
  24. HH>     l: string;
  25. HH> begin
  26. HH>   assign(t,'FILES.BBS');
  27. HH>   reset(t);
  28. HH>   while not eof(t) do
  29. HH>   begin
  30. HH>     readln(t,l);
  31. HH>     writeln(t);
  32. HH>   end;
  33. HH>   close(t);
  34. HH> end.
  35.  
  36. HH> ?????? I don't know what you are trying to accomplish, but it seems
  37. to
  38. HH> me that this does the same thing, and it's easier to
  39. HH> write/understand...
  40.  
  41. I agree, except for one thing, it will not correctly handle text files where
  42. there are "strings" longer than 255 characters.  Many text files are written
  43. by languages other than TP and have no 255 character string limit.
  44.  
  45. If you KNOW that no line is longer than 255 characters then Ok.  If you don't
  46. KNOW then a different design philosophy is necessary.
  47.  
  48. TeeCee
  49.  
  50.  
  51. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  52.  
  53.  
  54. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  55.  
  56. Conference 4
  57. Date       02-23-92 04:54:50
  58. From       Trevor Carlsen
  59. To         Jud Mccranie
  60. Subject    Re: New Reader!
  61.  
  62.  TCID:3343d39d 5b16
  63. JM> #2: TP 6 is not useless.  Looking at it without comparing it to
  64. JM> anything else, and it is a great compiler, etc.  However, there are
  65. JM> some that are much better - namely TP 5.0 and TP 5.5.
  66.  
  67. Previously I had thought that you were complaining about the IDE.  Now you
  68. are complaining about the compiler and yet I don't recall ever seeing one
  69. message from you detailing any problems with the compiler.
  70.  
  71. JM> #3: That is why I tried to make it clear that my statement is
  72. JM> probably the minority opinion.  (I'm beginning to wonder about that,
  73. JM> though.)...
  74.  
  75. There are exactly THREE contributors (I'll make that four because Ping has
  76. returned! even though it is months since he mentioned it) who regularly complainabout TP6 and three of those four are only complaining about the IDE, not
  77. the compiler.
  78.  There are many who have countered with opposing opinions.  I have no problems
  79. with what you do/do not like about TP6IDE... However it is becoming close
  80. to an echo-killer because of the frequency of the same old theme.  I'd like
  81. to see the subject
  82. cooled somewhat - it is becoming boring to many.
  83.  
  84. JM> My advise was absolutely impartial.  It is based entirely on the facts
  85. JM> of TP 5.5 vs 6.0.  I have nothing to gain either way, except that if
  86. JM> enough people realize how bad 6.0 is compared to 5.5 then maybe
  87.  
  88. The above comments just prove how partial your advice was, not how impartial!
  89. I'd like to hear about these "facts" on how TP5.5 is better than TP6 but
  90. with no reference to the IDE features which are a highly personal and subjectivelike/dislike thing and, for me and many others judging from my netmail about
  91. this, should
  92. have no bearing on the debate.
  93.  
  94. If you want to refer to the IDE then there is absolutely no doubt that the
  95. TP6 IDE is *vastly* superior in almost every way to the TP5 IDE.  Whether
  96. you like the new features or not, and whether the fact that it is a memory
  97. hog and is better
  98. suited to the more powerful and greater capacity machines, is an *entirely*
  99. different and very subjective question.
  100.  
  101. Turbo Vision is another story.  Borland could quite easily have chosen to
  102. include it only in the Professional Pack.  The fact that they didn't is to
  103. their credit.  Once any developer develops a large application with TV and
  104. overcomes the learning
  105. curve in so doing,  his/her productivity (which you make a lot of comments
  106. about) will increase enormously.  TV alone makes the upgrade essential to
  107. anyone even remotely interested in productivity.
  108.  
  109. I just wish I had pulled my head out of the sand earlier! :-)
  110.  
  111. TeeCee
  112.  
  113. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  114.  
  115.  
  116. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  117.  
  118. Conference 4
  119. Date       02-23-92 04:15:00
  120. From       Trevor Carlsen
  121. To         Chris Whitney
  122. Subject    TP6 is screwy! HELP!!
  123.  
  124.  TCID:abac9a6e 5b17
  125. CW> That's just the thing -- Stack & Range checking ARE enabled!
  126. CW> I have one integer variable that I set to 100 at the
  127. CW> beginning, and after you do some things, it suddenly goes to
  128. CW> -22000.  My code only sets it ONCE! How can it change if _I_
  129. CW> don't change it!?  (This happens to a few other variables
  130. CW> also, some are changed-some not.)
  131.  
  132. This should be very easy to find.  Just place a watch on that variable in
  133. the debugger so that you know exactly when it is getting trashed.  Once you
  134. know when, it should be a short step to how.
  135.  
  136. CW>  I set a large array to 177 sometimes, and this seems to be
  137. CW> the number some of the other variables get set to for no
  138. CW> apparent reason.  I think it's happening when I go thru two
  139. CW> for/do loops to scan & change a large 2D
  140. CW> array[1..170,1..140].  Could this be a problem if the user
  141. CW> causes this proc to run many times in a row?  I hope it's
  142. CW> not a Turbo Pascal virus!
  143.  
  144. I think that it is far more likely to be something you are doing wrong.
  145. Are you using dynamic variables or pointers at all?  If so check out their
  146. dereferencing very carefully.  Also check any of the block moves you might
  147. be using - they can
  148. be very dangerous if an error in using them is made eg Move, FillChar, BlockReaSet your string checking to strict {$V+}.  Check out any use of absolute
  149. variables in any procedures or functions.
  150.  
  151. What is the declaration of this large array?  I would really think that may
  152. be your problem in some way.  If it is global do you ever access it from
  153. a procedure or function after passing it as a parameter?
  154.  
  155. Failing all that make up a small demonstration program that will exhibit
  156. the problem and post it here.  If that is not possible give me a voice contact
  157. number and a convenient time (in GMT) and I'll call you to discuss it further.
  158.  
  159.  
  160. TeeCee
  161.  
  162. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  163.  
  164.  
  165. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  166.  
  167. Conference 4
  168. Date       02-23-92 04:03:40
  169. From       Trevor Carlsen
  170. To         Harald Harms
  171. Subject    var > 64
  172.  
  173.  TCID:74291c85 5b18
  174. > are assigned a value, you trash your stack. If there other heap
  175. > variables declared before it then they are what gets clobbered
  176. > instead of the stack.
  177. HH> Well, as of now, I haven't had any problems..This is the
  178. HH> only thing on the heap. An array of those things depending
  179. HH> on the size of file that needs to be copied, and I have
  180. HH> tested it with tons of files (I use it constantly), and I
  181. HH> haven't had a single problem!
  182.  
  183. Ok, if you do that no worries.  I just don't like seeing it given out as
  184. advice for someone to copy with no mention of the very real dangers involved.
  185.  
  186. TeeCee
  187.  
  188. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  189.  
  190.  
  191. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  192.  
  193. Conference 4
  194. Date       02-23-92 04:32:40
  195. From       Trevor Carlsen
  196. To         Mike Hindle
  197. Subject    Re: Variable number of parameters
  198.  
  199.  TCID:29f4bf52 5b19
  200. MH> ... I would just like to be able to write some routines of
  201. MH> my own that can handle optional parameters. An example would
  202. MH> be a Pos function that allows an optional parameter to
  203. MH> specify an index search interval.
  204.  
  205. MH> Ie: Pos(CodeStr,'0102030405,2) would return 5 if
  206. MH> CodeStr='03' but 0 if CodeStr='10'.
  207.  
  208. One of the real beauties of TP is that you CAN do all these things. Write
  209. your own and place them in a unit for future use.  The optional parameters
  210. becomes a little more tricky as that is not possible on this type of thing
  211. but that should
  212. not be a problem - have two functions, one with, and the one you already
  213. have - without.
  214.  
  215.  function IPos(k,t: string; i: byte): byte;
  216.    { Returns the position of k in t.  If k is not in t  or if k's position
  217. }
  218.    { in t is not on a boundary determined by i returns zero. MH>      }
  219.    var temp: byte;
  220.    begin
  221.      temp := pos(k,t);
  222.      IPos := temp * ord(temp mod i = 1);
  223.    end;
  224.  
  225. untested.
  226.  
  227. MH> Another thing I would like is to be able to imbed cursor
  228. MH> positioning commands in a Write() parameter list. Something
  229. MH> which nearly every implementation of BASIC allows but Pascal
  230. MH> doesn't.
  231.  
  232. Again write your own - use a TFDD like I showed you a couple of days ago
  233. but make it a little more elaborate.  TFDDs can be a very useful tool for
  234. all sorts of things.
  235.  
  236. TeeCee
  237.  
  238.  
  239.  
  240. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  241.  
  242.  
  243. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  244.  
  245. Conference 4
  246. Date       02-24-92 06:23:50
  247. From       Trevor Carlsen
  248. To         William Westlake
  249. Subject    Variables > 64K
  250.  
  251.  TCID:2f2f0f7b 5b6c
  252. WW> take a look at page 59 of the TP 6.0 Library reference....
  253. WW> And I quote.
  254.  
  255. WW>   " Restrictions:  The largest block that can be allocated
  256. WW> on the heap at one time is 65,521 bytes (64k-$F).  If the
  257. WW> heap is not fragmented, for example at the beginning of a
  258. WW> program, succesive calls to GetMem returns neighboring
  259. WW> blocks of memory. "
  260.  
  261. WW>   Now I ran a test and it looks as though TP will allow you
  262. WW> to actually allocate 65535 bytes on the heap in one shot.  I
  263. WW> did so and I wrote numbers to it all the way to the end and
  264. WW> it did not integer wrap.  At that point I do not know why
  265. WW> borland says that 65,521 is the limit.  Maybe someone from
  266. WW> Borland could answer this.....  As it stands though, since
  267. WW> 15 bytes is not worth the risk I am going to stick with
  268. WW> Borlands recomendations......
  269.  
  270. This was discussed here some time back.  Since TP6 came out with its improved
  271. heap handling methods the manual should have been changed to indicate that
  272. structures on the heap were now permissable up to 65528 bytes in size.  Even
  273. so integer
  274. wrap will not affect you unless the offset of the structure is 8 (in TP6
  275. it will always be 0 or 8).  As the heap always starts at a paragraph boundary,
  276. the only way a structure can get an offset of eight is if a variable of a
  277. size where sizeof(The_variable)
  278. mod 16 is in
  279. the range 1 to 8.
  280.  
  281. Obviously this makes TP6 far safer than TP5 where a structure could have
  282. an offset ranging from 0..15.  However you are very sensible to follow Borland'sguidelines, that way you will be safe and any source code you distribute
  283. will also be
  284. safe with TP4,5.0 and 5.5.
  285.  
  286. TeeCee
  287.  
  288. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  289.  
  290.  
  291. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  292.  
  293. Conference 4
  294. Date       02-24-92 06:48:00
  295. From       Trevor Carlsen
  296. To         Russell Ault
  297. Subject    Tp 6.0
  298.  
  299.  TCID:b20a0364 5b6d
  300. RA>  * MegaMail 2.10 #0:Go ahead, steal my tagline.
  301.      ^ was hi-bit char 254
  302. Russell, on the 30th January I requested that you cease placing hi-bit characterin your messages on the tear line.
  303.  
  304. If you received that message it seems that you have chosen to ignore it as
  305. not only have your tear lines continued to contain hi-bit characters but
  306. today you have posted some messages where you have enclosed a quoted message
  307. in a hi-bit character
  308. box.
  309.  
  310. I hope that the reason for this is that you did not see my message of the
  311. 30th.  If so, then consider this a friendly reminder of the echo's rules,
  312. if not, then consider this to be a final warning on the matter.  I would
  313. appreciate any reply
  314. to be by netmail.
  315.  
  316. (The reason hi-bit characters are banned in most Fido-net echoes is because
  317. a large number of readers do not read them using IBM compatibles and the
  318. hi-bit characters can wreak havoc with their screens.)
  319.  
  320. Trevor Carlsen
  321. Moderator.
  322.  
  323. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  324.  
  325.  
  326. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  327.  
  328. Conference 4
  329. Date       02-24-92 07:02:50
  330. From       Trevor Carlsen
  331. To         Ken Burrows
  332. Subject    Menu Files
  333.  
  334.  TCID:66d92586 5b6e
  335. KB> This space stays allocated until you use the DISPOSE
  336. KB> procedure.
  337.  
  338. KB> New and Dispose require a lot of programming discipline to
  339. KB> operate properly. Whereas heap space may be semingly
  340. KB> arbitrary, its allocation is quite linear and functions like
  341. KB> a stack. Dispose'ing of pointers must be done in reverse
  342. KB> order of the New'ing them.
  343.  
  344. An excellent explanation of dynamic memory and a linked list Ken.  However...
  345.  
  346. I disagree with the last sentence of the above excerpt. Pointers may be disposedof in any order the program/mer sees fit.  Obviously there are certain caveats
  347. to this in the case of linked lists but the point is it can be done.  If
  348. a pointer
  349. is disposed of before a pointer that was initialised after it is disposed,
  350. no problems occur other than an unallocated "hole" in the heap.  This hole
  351. is not lost however as it becomes part of the free list linked list and can
  352. be re-allocated
  353. by the heap manager at any
  354. time.
  355.  
  356. Obviously a good programmer will try and adopt methods that minimise this
  357. heap fragmentation but there are times that it is unavoidable.
  358.  
  359. TeeCee
  360.  
  361. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  362.  
  363.  
  364. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  365.  
  366. Conference 4
  367. Date       02-24-92 07:16:20
  368. From       Trevor Carlsen
  369. To         Sean Dorsey
  370. Subject    Write to own self
  371.  
  372.  TCID:d343cbb9 5b6f
  373. SD> I am looking for the code to modeify the program at runtime
  374. SD> and resave itself.  I know everyone has at one time or
  375. SD> another run a program that saved the setup paramaters to
  376. SD> itself, Qedit, Tdraw, etc etc.  How do I do this?  I want to
  377. SD> write some information (mostly text strings) that can be
  378. SD> changed and re-written to the file without re-compiling.
  379.  
  380. It is a simple matter to code this and I have several times posted code to
  381. demonstrate how.  You can probably find my unit SELFMOD.xxx on a BBS near
  382. you.
  383.  
  384. It would be wise however to look at your reasons for doing this.  Most modern
  385. programs are now avoiding this technique in favour of configuration files.
  386. This makes the detection of virus attacks easier and also avoids problems
  387. with networks,
  388. exe packers such as PKLite etc.
  389.  
  390. If you still wish to do this and can't find SELFMOD closer to you, you are
  391. welcome to FREQ it from me.  (Magic name SELFMOD about 2500 bytes)
  392.  
  393. TeeCee
  394.  
  395. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  396.  
  397.  
  398. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  399.  
  400. Conference 4
  401. Date       02-24-92 07:29:30
  402. From       Trevor Carlsen
  403. To         John Gohde
  404. Subject    Complaints
  405.  
  406.  TCID:550ab9c5 5b70
  407. JG> Dear Conference Moderator:
  408. JG> TeeCee, I am  hereby making a formal complaint  against the
  409. JG> above TWIT. Disagreeing with  ones position is one thing,
  410. JG> but this out right undisguised assault is entirely a
  411. JG> different matter!!!!
  412.  
  413. I have replied by netmail, which is where the above should have been. Let
  414. me know here (if you still have access to this echo) if you do not receive
  415. it.
  416.  
  417. Trevor Carlsen
  418. Moderator.
  419.  
  420.  
  421. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  422.  
  423.  
  424. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  425.  
  426. Conference 4
  427. Date       02-24-92 08:13:20
  428. From       Trevor Carlsen
  429. To         Derek Mahar
  430. Subject    Enhanced Readkey function
  431.  
  432.  TCID:2af8cbff 5b71
  433. DM> The problem with the function is that it returns the
  434. DM> same word value for every key pressed.
  435.  
  436. DM> FUNCTION ReadKeyEnhanced : WORD;
  437. DM> begin
  438. DM>   ASM
  439. DM>     MOV AH, 10h
  440. DM>     INT 16h
  441. DM>   END;
  442. DM> end;
  443.  
  444. You should be coding this as a macro to do it this way. So -
  445.  
  446.  function ReadKeyEnhanced: word; assembler;
  447.    asm
  448.      mov ah, 10h
  449.      int 16h
  450.    end;
  451.  
  452. will (or should) do the trick.  Untested.
  453.  
  454. Another method would be to use your code and add the line -
  455.  mov @result, ax
  456. immediately following the int 16h.
  457.  
  458. Read up on the differences between procedural macros and ordinary procedures/funon pages 294 and 303..307 in the Programmer's Guide.
  459.  
  460. TeeCee
  461.  
  462. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  463.  
  464.  
  465. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  466.  
  467. Conference 4
  468. Date       02-24-92 12:59:30
  469. From       Trevor Carlsen
  470. To         David Cohen
  471. Subject    Opro/FlexWrite
  472.  
  473.  TCID:b4426df8 5b72
  474. DC> There's a routing called flexwrite and the actual code is in an
  475. DC> assembly
  476. DC> module supplied with opro. it supports 4 colors, i just need a few
  477. DC> more colors. I'm sure it's probably a simple change of the code to
  478. DC> support 6 instead of 4, anyone feel like checking it out?
  479.  
  480. Actually it supports the default colour -TAttr[0] and three other colours
  481. all of which are user defined. This is hard coded into the obj file.
  482.  
  483. Why would you want more than three extra colours for one string?  If you
  484. want to change the colours at any time it is just a matter of changing the
  485. values of the control array TAttr.  You can do that anywhere in your program
  486. as many times as
  487. you wish.
  488.  
  489. TeeCee
  490.  
  491.  
  492. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  493.  
  494.  
  495. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  496.  
  497. Conference 4
  498. Date       02-24-92 13:15:10
  499. From       Trevor Carlsen
  500. To         Ken Koch
  501. Subject    Basm ??
  502.  
  503.  TCID:7501938e 5b73
  504. KK> ... Whats BASM?. I figure just by the ASM in it that it is
  505. KK> an Assembler of sorts, but can it be that they're talking
  506. KK> about TASM (from Borland) or is BASM a Borland product too.
  507. KK> And if not, what's it doing in the PASCAL echo.
  508.  
  509. I think that BASM stands for Built-in ASseMbler.  This was included as one
  510. of the major enhancements introduced with TP6.  For anybody who has experienced
  511. the hassles of designing a long in-line segment it is a god-send.
  512.  
  513. Also I just wish to correct what appears to be an incorrect understanding
  514. of this echo.  It is not devoted to Borland or Borland products but to the
  515. Pascal language of which Turbo Pascal is a major dialect.  Because of TPs
  516. defacto status as
  517. the standard by which other PC-DOS-based compilers are measured it probably
  518. represents 99.9% of all on-topic messages here. That should not deter those
  519. who wish to discuss other Pascals for DOS or any other platform.
  520.  
  521. TeeCee
  522.  
  523.  
  524.  
  525. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  526.  
  527.  
  528. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  529.  
  530. Conference 4
  531. Date       02-23-92 02:23:00
  532. From       Terry Hughes
  533. To         Rob Kittredge
  534. Subject    OPRO help
  535.  
  536.  RK>This way, like you do in MAKESCRN, if I change one constant
  537. RK>I don't have to
  538. RK>change the rest of them on down the line.  This works fine
  539. RK>for the compilation of the program using TP 6.0, but
  540. RK>MAKEHELP will not recognize the ' + 1's' and therefore
  541. RK>will not compile the help file.  I have managed to modify
  542. RK>MAKEHELP to support the +1's but was wondering if you had
  543. RK>plans to modify MAKEHELP on your end sometime.  If you want
  544. RK>to see my changes, let me know and i'll U/L them to the
  545. RK>TurboPower BBS for you...
  546. No, that's not something we've done or considered doing. However,
  547. it sounds like a useful modification. Why don't you go ahead and
  548. upload the changes to our BBS. Even if we don't officially incorporate
  549. them into MAKEHELP others might find them useful.
  550. Thanks.
  551. -Terry
  552.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  553.  * Origin: The Programmers Playhouse (1:128/60)
  554. --- Dogfight 2.05 #2
  555.  
  556. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  557.  
  558. Conference 4
  559. Date       02-23-92 02:23:00
  560. From       Terry Hughes
  561. To         Janjaap Streefkerk
  562. Subject    Re: PRINTER UTILITIES
  563.  
  564.  JS>Thanks once again for spending a little of your time
  565. JS>answering my question concerning printer support from
  566. JS>within Turbo Vision. This will be the last time I'll
  567. JS>bother you. Could you give me adress, phone, fax or
  568. JS>anything else, where I could contact Turbo Power, for
  569. JS>their 'Object Professional'. And do you know if it's sold
  570. JS>outside the USA ? Preferrably the Netherlands of course.
  571. JS>Bye bye from a Vision-lover.
  572. You can contact us, TurboPower Software, at 719-260-6641. Our
  573. address is:
  574.   TurboPower Software
  575.   PO Box 40990
  576.   Colorado Springs CO 80949
  577. We have two dealers in the Netherlands: PC Computing at De Bergkamp
  578. 24 in Overloon or Lemax at Schipholweg 335-A in Badhoevedorp.
  579. -Terry
  580.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  581.  * Origin: The Programmers Playhouse (1:128/60)
  582. --- Dogfight 2.05 #2
  583.  
  584. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  585.  
  586. Conference 4
  587. Date       02-23-92 02:23:00
  588. From       Terry Hughes
  589. To         Alex Boisvert
  590. Subject    Creating a text editor.
  591.  
  592.  AB>TC> In fact a direct quote from the documentation - "..., the
  593. AB>TC> TextEditor provides a host of new editing commands, and the
  594. AB>TC> result is a plug-and-play editor comparable in power to the Turbo
  595. AB>TC> Pascal editor."
  596. AB>Except for one MAJOR drawback...  It cannot edit files larger
  597. AB>than 64k, which is an understandable limitation.
  598. It's was a limit we accepted given the target use for that text
  599. editor.
  600. For those folks that need to edit larger files there is a
  601. derived editor object on our BBS (719-260-9726) that does so
  602. (called OPBIGED.LZH I believe).
  603. -Terry
  604.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  605.  * Origin: The Programmers Playhouse (1:128/60)
  606. --- Dogfight 2.05 #2
  607.  
  608. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  609.  
  610. Conference 4
  611. Date       02-24-92 02:24:00
  612. From       Terry Hughes
  613. To         Eddie Braiter
  614. Subject    Turbo Power address
  615.  
  616.  EB>I'm looking to possibly purchase a copy of Turbo Power. I
  617. EB>need to know who makes it and their address.
  618. TurboPower Software is the name of our company. We make several
  619. products that are sometimes mentioned in this echo (notably,
  620. Object Professional, Async Professional and B-Tree Filer).
  621. You can reach us at 719-260-6641, 800-333-4160 or PO Box
  622. 49009 Colorado Springs CO 80949.
  623. -Terry
  624.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  625.  * Origin: The Programmers Playhouse (1:128/60)
  626. --- Dogfight 2.05 #2
  627.  
  628. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  629.  
  630. Conference 4
  631. Date       02-24-92 02:24:00
  632. From       Terry Hughes
  633. To         Jan Feijes
  634. Subject    Simultaneous serial I/O
  635.  
  636.  JF>The IRQ line is normally high (open collector output). When
  637. JF>the interrupt is being given, the interrupt line is simply
  638. JF>pulled down. When two devices pull the line down there
  639. JF>should be no problem.
  640. JF>Placing more than one device on one interrupt line should
  641. JF>not give any problems. If they do there is something
  642. JF>defenitly wrong. I have never heard of a case where an
  643. JF>interrupt is pushed to the positive supply rail, they all
  644. JF>use an open collecctor config:
  645. I'm not well versed enough in hardware to dispute your comment.
  646. What you say, however, is different from how every other
  647. hardware person I've talked to (including a serial board
  648. manufacturer) has described the issue. And that is that the AT
  649. bus cannot share an interrupt between devices on two different
  650. boards because both will be driving the IRQ at the same time.
  651. And that's pretty much what our subsequent testing showed. Our
  652. interrupt sharing code works fine on PS/2s but not on ATs or
  653. XTs. On those machines we would sometimes get the interrupt,
  654. sometimes not.
  655. I noticed your reply said this "should" work. Have you actually
  656. tried sharing an IRQ between two simultaneously open serial
  657. ports on two different boards in an AT? If you've gotten such a
  658. setup to work reliably I'd be interested in hearing more about
  659. it.
  660. -Terry
  661.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  662.  * Origin: The Programmers Playhouse (1:128/60)
  663. --- Dogfight 2.05 #2
  664.  
  665. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  666.  
  667. Conference 4
  668. Date       02-24-92 02:24:00
  669. From       Terry Hughes
  670. To         Dennis Lozen
  671. Subject    Chain
  672.  
  673.  DL>I'm looking for a TP6 unit that will chain programs, there
  674. DL>used to be one available for tp4/tp5 but won't work with
  675. DL>tp6 because it uses the FreePtr variable which is no longer
  676. DL>in TP6...
  677. We updated the public domain CHAIN unit to work with Turbo
  678. Pascal 6 way back when TP6 first came out. You can get the most
  679. recent version of CHAIN from our BBS (719-260-9726).
  680. -Terry
  681.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  682.  * Origin: The Programmers Playhouse (1:128/60)
  683. --- Dogfight 2.05 #2
  684.  
  685. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  686.  
  687. Conference 4
  688. Date       02-23-92 00:06:40
  689. From       Mark Ouellet
  690. To         Jud Mccranie
  691. Subject    Re: TP 6.0
  692.  
  693.     On 17 Feb 92, you, Jud Mccranie, of 1:370/520.0 wrote...
  694. KL>> I agree.  I've seen the IDE of TP 6.0 on advertisements and my
  695. KL>> very first impression is that it is too fancy for a programming
  696. KL>> interface.
  697. JM> Ablosutely right.  It is not designed to be useful to programmers, it
  698. JM> is designed to look like a Windows program.  I had a strong suspicion
  699. JM> that they were going to screw up everything when their C compiler got
  700. JM> that kind of interface, and the stand-alone degugger, etc too.  I think
  701. JM> I wrote to them and warned them to not screw up TP too, but they did
  702. JM> it any way.
  703. Jud,
  704.        Unless you got TC++ I suggest you refrain from such
  705. comments before you really have a chance to test it. TC++'s
  706. interface is a programmer's dream come true. It's project
  707. management is superb and the interface is a charm.
  708.        BTW, if you don't have a mouse then I guess you
  709. might not see all that is available with TP 6.0. I had my
  710. mouse for some time before getting TP 6.0 but only started
  711. using it with TP 6.0.
  712.        Also note that I am totally opposed to windows, I
  713. hate it and would gladly have the microsoft team shot ;-)
  714. But the IDE is far from a Windows program. I also use DV,
  715. and that is an important difference, I hate windows because
  716. it wastes CPU time on useless graphical stuff. Who needs an
  717. analog clock that can fill the screen or a reversi game.
  718. Take the graphics out of windows and I might consider using
  719. it. What i hate most about it is it's way of emulating an
  720. 8088 with a 486. Take all the stuff that is slowing it down
  721. out and it becomes a possibly usefull interface.
  722.        Best regards,
  723.        Mark Ouellet.
  724. * Origin: One Beer gets me Drunk.... Usualy the 47th ;-) (Fidonet 1:240/1.4)
  725.  
  726.  
  727. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  728.  
  729. Conference 4
  730. Date       02-26-92 12:45:40
  731. From       Trevor Carlsen
  732. To         Mike Copeland
  733. Subject    Is this a compiler (TP5.5) bug?
  734.  
  735.  TCID:7d0a840a 5c27
  736. MC>    I encountered something I _think_ is a bug in TP5.5: indirect
  737. MC> referencing of a pointer structure causes a false "Type mismatch"
  738. MC> error. Here's a definition I have in my global data Unit:
  739.  
  740. Mike that compiled perfectly for me in both TP5.5 and TP6. Can you demonstrate
  741. it in a small enough program to show here?
  742.  
  743. TeeCee
  744.  
  745. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  746.  
  747.  
  748. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  749.  
  750. Conference 4
  751. Date       02-26-92 16:42:10
  752. From       Trevor Carlsen
  753. To         Harald Harms
  754. Subject    interpreting ansifiles
  755.  
  756.  TCID:759d2e92 5c28
  757. HH> Your procedure doesn't handle the ansi chars. I am also
  758. HH> looking for a good way to display ansi files without the use
  759. HH> of ansi.sys. Something like a tpu or whatever .. anyone got
  760. HH> any ideas???
  761.  
  762. Look for a unit called PANSI*.*.  That will do the job you are asking about.
  763. Written by Ping Hansen from Denmark.
  764.  
  765. TeeCee
  766.  
  767. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  768.  
  769.  
  770. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  771.  
  772. Conference 4
  773. Date       02-26-92 16:47:20
  774. From       Trevor Carlsen
  775. To         Steve Sparks
  776. Subject    File Checking
  777.  
  778.  TCID:8d8bba37 5c29
  779. SS> function fileexist(name:str80) : boolean;
  780. SS>          var
  781. SS>           f:file;
  782. SS>         begin
  783. SS>           assign(f,name);
  784. SS>          {$i-}
  785. SS>            reset(f);
  786. SS>          {$i+}
  787. SS>         if ioresult <> 0 then fileexist:=false
  788. SS>                          else begin
  789. SS>                                 close(f);
  790. SS>                                 fileexist:=true;
  791. SS>                               end;
  792. SS>        end;
  793.  
  794. The difficulty with using something like this is that it will not detect
  795. files that are Read Only, Hidden and System and may thus return erroneous
  796. results.  Network operation may also present problems.
  797.  
  798. TeeCee
  799.  
  800. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  801.  
  802.  
  803. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  804.  
  805. Conference 4
  806. Date       02-26-92 16:53:30
  807. From       Trevor Carlsen
  808. To         Beeen Vegiard
  809. Subject    Stack Overflow Control
  810.  
  811.  TCID:78f05c43 5c2a
  812. BV> I have a number of procedures that call one another and make
  813. BV> extensive use of a UNIT of misc. items (that I wrote) such
  814. BV> as storeing part of screen text and attributes, restoreing
  815. BV> them, cursor size control, etc. I also tend to use variables
  816. BV> defined withing the procedures (dynamic)
  817.  
  818. BV> I began experiencing stack overflow errors in one of my
  819. BV> procedures that was called from a procedure that was called
  820. BV> from a procedure  (5 calls in all) I eliminated that problem
  821. BV> by killing the main menu and title screen procedures and
  822. BV> placing them in the main program body.
  823.  
  824. BV> Now I am getting the errors again.  I have my stack
  825. BV> decloration in the MEMORY SIZE option maxed out.  I don't
  826. BV> believe it would be possible to move any more procedures
  827. BV> into my main body, and I have eliminated most variables that
  828. BV> are unnecasary.
  829.  
  830. BV> My question is how can I get some more room on the stack? ...
  831.  
  832. You can't.  64K is the limit.  I think you should look carefully at how you
  833. are designing this program.  Large structures should be not be declared as
  834. local variables unless you store them on the heap as that is one sure way
  835. to quickly run
  836. out of stack space.  Passing large variable parameters by value rather than
  837. by reference is another way to shoot yourself in the foot with stack space.
  838.  
  839. I have written some very big programs.  I have never had a need for more
  840. than the maximum stack space and in most cases 16K is more than enough.
  841.  
  842. TeeCee
  843.  
  844. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  845.  
  846.  
  847. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  848.  
  849. Conference 4
  850. Date       02-23-92 20:20:00
  851. From       Norbert Igl
  852. To         Greg Williams
  853. Subject    graphics / calling converntions
  854.  
  855.  >         PROCEDURE PlotPoint1(x,y,colour: INTEGER);
  856. >         PROCEDURE PlotPoint2(x,y,colour: INTEGER);
  857. >         PROCEDURE PlotPoint3(x,y,colour: INTEGER);
  858. >       { Routine to draw a line, using a user-supplied
  859. >         point-plotting function in the form:
  860.  type     POINTFUNC = Procedure(x,y,color: INTEGER);
  861. >         PROCEDURE PlotLine(x1,y1,x2,y2: INTEGER; pointfunc: POINTER);
  862. > and call:
  863. >         PlotLine(5, 5, 10, 10, @PlotPoint2);
  864.  Procedure Plotline(x1,y1,x2,y2:integer; PlotIt:PointFunc);
  865.  Const  Co : Integer = 15;
  866.  Var    x,y : integer;
  867.  begin
  868.    for x := x1 to x2 do
  869.      for y := y1 to y2 do
  870.      begin
  871.        [..Your Line-drawing-Algorythm...]
  872.        If Condition_to_Plot
  873.             then PlotIt(x, y, Co);
  874.        [...more code...]
  875.      end;
  876.  end;
  877.   not testet....
  878. Bye from Germany, Norbert
  879. * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
  880.  
  881.  
  882. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  883.  
  884. Conference 4
  885. Date       02-26-92 02:26:00
  886. From       Terry Hughes
  887. To         Beeen Vegiard
  888. Subject    Re: Execute With Swap
  889.  
  890.  BV>WV>  >> My version of EXECSWAP works fine with TP 6.0.
  891. BV>Hey, I am looking for something along these lines.  Where can I pick it
  892. BV>up at?
  893. Our BBS (719-260-9726) still has a copy of the old EXECSWAP on
  894. it. And that unit works just fine with TP6 without any
  895. modifications. The only difference using it under TP6 is that
  896. you don't have to do anything special to save the free list
  897. (i.e., passing HeapPtr for LastToSave will save the entire heap
  898. and free list automatically).
  899. -Terry
  900. * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  901. * Origin: The Programmers Playhouse (1:128/60)
  902.  
  903.  
  904. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  905.  
  906. Conference 4
  907. Date       02-26-92 02:26:00
  908. From       Terry Hughes
  909. To         Brandon Jones
  910. Subject    Execute With swap
  911.  
  912.  BJ>Hello Wilbert!
  913. BJ>Answering a msg of <18 Feb 92>, from Wilbert Van.leijen to Joy Mukherjee:
  914. BJ>I would be interested in that ExecSwap code as well. I need
  915. BJ>ExecSwap badly, check out the origin line, should explain
  916. BJ>it. I can't find it anywhere!
  917. You can get it from the TurboPower Software BBS (719-260-9726).
  918. -Terry
  919. * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  920. * Origin: The Programmers Playhouse (1:128/60)
  921.  
  922.  
  923. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  924.  
  925. Conference 4
  926. Date       02-27-92 15:51:10
  927. From       Trevor Carlsen
  928. To         Scott Kearney
  929. Subject    Readkey
  930.  
  931.  TCID:dd6bfadc 5c75
  932. SK> I am in a jam..  I have given a program arrow-key support,
  933. SK> but have found that the capital letters P and H, or
  934. SK> something like that, are pretty much counted as arrow keys..
  935.  
  936. SK> Not a problem since the input was mainly numerical..  But
  937. SK> now I have to allow the user to enter in a name, and
  938. SK> whenever they hit a capital P or H, it will recognize it as
  939. SK> an arrow key and therefore won't accept names like "Harvey"
  940. SK> or something..
  941.  
  942. SK> I looked it up, it says that the arrow key (for the example
  943. SK> here, we'll say up) is the ascii code for P (I think),
  944. SK> preceded by a null (ascii 0), but the condition "If Kch =
  945. SK> Chr(0) + Chr(72)" produced an error..
  946.  
  947. SK> How can I use arrow keys, without having them count as
  948. SK> letters also?
  949.  
  950. There are two different types of keys on a keyboard, "ordinary" keys - such
  951. as the alpha-numeric keys, and "special" or "extended" keys - such as the
  952. cursor control keys and the function keys.  When an ordinary key is pressed,
  953. ReadKey returns
  954. the code for that key. When a special key is pressed, ReadKey returns a
  955. nul character and there is another character still waiting in the buffer.
  956. This next character is the scancode of the special key.
  957.  
  958. So to handle special keys you simply need to read two characters from the
  959. buffer.  Here is a simple routine to handle this -
  960.  
  961.  function SpecialKey(var ch: char): boolean;
  962.    begin
  963.      ch := ReadKey;
  964.      if ch = #0 then { it was a special key } begin
  965.        SpecialKey := true;
  966.        ch := ReadKey;  { so get the scancode }
  967.      end
  968.      else SpecialKey := false;
  969.    end;  { SpecialKey }
  970.  
  971. The best way to use such a function is to have a unit with the various keys
  972. defined as constants like this -
  973.  
  974. const  { Key codes }
  975.  { Special keys }
  976.  F1  = $3b; ShF1  = $54; CtrlF1  = $5e; AltF1  = $68;
  977.  F2  = $3c; ShF2  = $55; CtrlF2  = $5f; AltF2  = $69;
  978.  F3  = $3d; ShF3  = $56; CtrlF3  = $60; AltF3  = $6a;
  979.  F4  = $3e; ShF4  = $57; CtrlF4  = $61; AltF4  = $6b;
  980.  F5  = $3f; ShF5  = $58; CtrlF5  = $62; AltF5  = $6c;
  981.  F6  = $40; ShF6  = $59; CtrlF6  = $63; AltF6  = $6d;
  982.  F7  = $41; ShF7  = $5a; CtrlF7  = $64; AltF7  = $6e;
  983.  F8  = $42; ShF8  = $5b; CtrlF8  = $65; AltF8  = $6f;
  984.  F9  = $43; ShF9  = $5c; CtrlF9  = $66; AltF9  = $70;
  985.  F10 = $44; ShF10 = $5d; CtrlF10 = $67; AltF10 = $71;
  986.  Home       = $47; Endkey     = $4f; PageUp     = $49;
  987.  PageDn     = $51; UpArrow    = $48; DownArrow  = $50;
  988.  LeftArrow  = $4b; RightArrow = $4d; Escape     = $1b;
  989.  Insert     = $52; Delete     = $53;
  990.  { Ordinary keys }
  991.  BackSpace  = $08; Tab        = $09; Enter      = $0d;
  992.  Tab_left   = $0f;
  993.  
  994. Now you can code it like this -
  995.  
  996.  if SpecialKey then { Process special key }
  997.    case ch of
  998.      UpArrow  :
  999.      DownArrow:   etc...
  1000.    end { case }
  1001.  else { ordinary key }
  1002.    Process ordinary key
  1003.  
  1004. TeeCee
  1005.  
  1006. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1007.  
  1008.  
  1009. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1010.  
  1011. Conference 4
  1012. Date       02-27-92 16:40:40
  1013. From       Trevor Carlsen
  1014. To         Russell Ault
  1015. Subject    High Bit Chars
  1016.  
  1017.  TCID:81c8c250 5c76
  1018. RA> unwanted high bit character inclusions?  Nip the problem off at the
  1019.  
  1020. RA> source if possible, that way.  I can't have been the only one whose
  1021.  
  1022. RA> software was giving others unsuspected grief.
  1023.  
  1024. True...  However the problem is usually easily fixed as it is a configuration
  1025. option in most packages.  Just mention it to your sysop and/or check out
  1026. the way you have the reader set up.
  1027.  
  1028. TeeCee
  1029.  
  1030. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1031.  
  1032.  
  1033. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1034.  
  1035. Conference 4
  1036. Date       02-28-92 03:49:20
  1037. From       Trevor Carlsen
  1038. To         Norbert Igl
  1039. Subject    Dates
  1040.  
  1041.  TCID:61b19091 5ce4
  1042. > To find the difference in seconds between any two times, they must
  1043. > first be converted to the number of seconds from a common datum.
  1044.  
  1045. NI>   ....no big deal, is it ?
  1046.  
  1047. No...just one heck of a lot of unnecesary work for nothing!  Far easier to
  1048. do things in a linear way - with the added advantage that it can be done
  1049. in ISRs whereas yours cannot.
  1050.  
  1051. TeeCee
  1052.  
  1053. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1054.  
  1055.  
  1056. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1057.  
  1058. Conference 4
  1059. Date       02-28-92 05:33:20
  1060. From       Trevor Carlsen
  1061. To         Norbert Igl
  1062. Subject    Variable number of parameters
  1063.  
  1064.  TCID:29f448e0 5ce5
  1065. NI>    this question was a topic a while ago,
  1066. NI>    and *no* solution was found....
  1067.  
  1068. That is not quite true...(depending on the exact needs).  In the example
  1069. you have posted it is unnecessary to go to all that trouble.
  1070.  
  1071. NI>    ( HI, TeeCee, another one for your collection...)
  1072.  
  1073. A very simple TFDD (text file device driver) as I posted here on 20th February
  1074. will do nicely. (As your message was dated 18th February, I am sorry that
  1075. you went to such a lot of effort to help find a solution because you would
  1076. not have seen
  1077. the very simple solution with real variable parameters.)
  1078.  
  1079. NI>  CallWithManyParams
  1080. NI>      ('"MA is" 31 "Years old and got" 2 "children"');
  1081. NI>  CallWithManyParams
  1082. NI>      ('"PA is" 34 "Years ols and earns" 1250.50 "Dollars a week"');
  1083. NI>  CallWithManyParams
  1084. NI>      ('" Long Long Real " 65536 -1 -33.55');
  1085.  
  1086. Using a TFDD the above is just a matter of -
  1087.  
  1088.  write(FStr,'MA is ',MaAge,' Years old and got ',NumbOfKids,' children');
  1089.  FormattedStr := GetFStr(FStr);
  1090.  
  1091. No parsing, no hassles, much faster and a variable number of parameters.
  1092.  
  1093. TeeCee
  1094.  
  1095. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1096.  
  1097.  
  1098. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1099.  
  1100. Conference 4
  1101. Date       02-28-92 04:18:40
  1102. From       Trevor Carlsen
  1103. To         Jesse Sipprell
  1104. Subject    Re: Variable number of parameters
  1105.  
  1106.  TCID:29f4f941 5ce6
  1107. TC> Again write your own - use a TFDD like I showed you a couple
  1108. TC> of days ago but make it a little more elaborate.  TFDDs can
  1109. TC> be a very useful tool for all sorts of things.
  1110.  
  1111. JM> A TFDD??  I assume this stands for Text File Device
  1112. JM> [something]?  Are you talking about using a file variable to
  1113. JM> point to far routines that process the output stream?
  1114.  
  1115. Exactly. (TFDD = Text File Device Driver)
  1116.  
  1117. TeeCee
  1118.  
  1119. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1120.  
  1121.  
  1122. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1123.  
  1124. Conference 4
  1125. Date       02-28-92 04:24:30
  1126. From       Trevor Carlsen
  1127. To         Jud Mccranie
  1128. Subject    Tp 6.0 Ide
  1129.  
  1130.  TCID:10b85719 5ce7
  1131. JF> I have a nice little program it uses 8.5 Megabyte (one
  1132. JF> executable...) It also uses several external files...
  1133. JF> <GRIN>
  1134.  
  1135. JM> And you are able to run it in the TP 6 IDE?  I don't see
  1136. JM> how.  My largest is 650K of my source, uses a lot of TPro
  1137. JM> units, generates about 390K EXE, and it won't even come
  1138. JM> close to running in the TP 6 IDE.  What's your secret?
  1139.  
  1140. There is something *really* strange here.  Are you saying that you not only
  1141. compile "big" programs with the IDE compiler but that you also RUN them from
  1142. there?
  1143.  
  1144. Even if I used the IDE as my editor/compiler, I would not consider testing
  1145. them from there.  It is just not a sound way to do things.  Once your customers
  1146. have the program they will not be using the IDE to run them and thus your
  1147. testing becomes
  1148. invalid.  As testing and debugging is such a time consuming and critical
  1149. phase of development, one cannot afford to waste time doing it in a non-real
  1150. situation.
  1151.  
  1152. I can understand programmers liking the convenience of the IDE for editing
  1153. and compiling but honestly believe it is a false convenience if they extend
  1154. this to the testing stage.
  1155.  
  1156. TeeCee
  1157.  
  1158.  
  1159. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1160.  
  1161.  
  1162. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1163.  
  1164. Conference 4
  1165. Date       02-28-92 04:37:10
  1166. From       Trevor Carlsen
  1167. To         Jud Mccranie
  1168. Subject    New Reader!
  1169.  
  1170.  TCID:33435de8 5ce8
  1171. JM> Actually I meant the 6.0 IDE when I said the compiler.
  1172. JM> There's nothing wrong with the actual compiler as far as I'm
  1173. JM> concerned.  I used "compiler" where I meant the whole
  1174. JM> package - including the IDE.
  1175.  
  1176. JM> I can't fault the compiler, I meant the IDE.
  1177.  
  1178. JM> that the 5.5 IDE is better than the 6.0 IDE.  The debate is
  1179. JM> over whether the benefits of the 6.0 compiler over the 5.5
  1180. JM> one are enough to bite the bullet and use 6.0.  In my
  1181. JM> opinion, it is not even close, since (1) I don't do any
  1182. JM> assembler, (2) the 286 option doesn't help appreciably, (3)
  1183. JM> I figured out a long time ago how to fake a conditional
  1184. JM> breakpoint in the 5.x IDE, (4) I don't like TV, I use TPro
  1185. JM> instead.
  1186.  
  1187. You and I will agree to disagree.
  1188. 1. I too avoid using assembler if possible.  However I have never yet written
  1189. a large program that didn't benefit from using it somewhere.
  1190. 2. ALL my customers use '286 (or later) based machines.  As I do not write
  1191. anything destined for the mass market I use the 286 option.  I have never
  1192. really checked if there is any real benefit (in my case) gained from doing
  1193. this.
  1194. 3. Fine! :-)
  1195. 4. They are two different products with two different aims.  I cannot see
  1196. the point in the point!  There is much in TPro not in TV and vice versa.
  1197.  
  1198. TC> If you want to refer to the IDE then there is absolutely no
  1199. TC> doubt that the TP6 IDE is *vastly* superior in almost every way
  1200. TC> to the TP5 IDE.  Whether you like the new features or not, and
  1201. TC> whether the fact that it is a memory hog and is better suited
  1202. TC> to the more powerful and greater capacity machines, is an
  1203. TC> *entirely* different and very subjective question.
  1204.  
  1205. JM> Have you ever tried to run a large program in the 6.0 IDE?
  1206. JM> It won't fit.  Have you ever tried to do a find or find&
  1207. JM> replace, with differnt options?  Very hard to use.  Ever
  1208. JM> tried to change the radio buttons? Very hard to do.
  1209.  
  1210. No.  My main application doesn't come close to being able to run from the
  1211. TP5 IDE so there is no hope in the TP6.  In any event why run any program
  1212. from an IDE - except little Q&Ds.  The other points I can't comment on as
  1213. they are purely subjective.
  1214.  TP5IDE's F&R is very clumsy for me and if TP6IDE's is worse well it bears
  1215. not thinking about, however I wonder sometimes if it is as bad as you make
  1216. out.  Perhaps your config?
  1217.  
  1218. JM> How can you say that whether or not is it a memory hog is
  1219. JM> subjective? I have both systems optimized, and I get 24K
  1220. JM> more in 5.5 than 6.0. And that is crucial in whether or not
  1221. JM> I can run my large programs.
  1222.  
  1223. It is subjective because there are other options. If you can RUN your programs
  1224. in the TP5 IDE then they are not very big.  Even the TP5 IDE uses some 250K.
  1225.  
  1226. JM> But, if there weren't 3rd-party packages that are better
  1227. JM> than TV I'd jump on the 6.0 bandwagon in a second.  The
  1228. JM> problems with the 6.0 IDE are minor compared to TV vs.
  1229. JM> nothing.  However, with 6.0 + TV stacked up against 5.5 with
  1230. JM> a 3rd party package, there is no contest.
  1231.  
  1232. The trouble is, there are not any third party packages competing with TV
  1233. and that's the whole point. (If there are any, I am unaware of them.)
  1234.  
  1235. TeeCee
  1236.  
  1237. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1238.  
  1239.  
  1240. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1241.  
  1242. Conference 4
  1243. Date       02-28-92 05:03:00
  1244. From       Trevor Carlsen
  1245. To         Patrick Valade
  1246. Subject    Help on Interrupts and TSR's
  1247.  
  1248.  TCID:2e51d847 5ce9
  1249. PV>     I'm writing a TSR that a teacher requested...  Basically
  1250. PV> I need to capture input from the keyboard before it gets to
  1251. PV> the main program.  I have a working model but the TSR
  1252. PV> returns two characters instead of one (the main program
  1253. PV> isn't affected by this doubling).  The program works like
  1254. PV> this...
  1255.  
  1256. PV> I'm using int 09 to activate my capture procedure, I then
  1257. PV> call int 16/AH=01h to check the buffer for any keys.  That's
  1258. PV> basically it right now. It works but it's anoying to see two
  1259. PV> characters comming up. Secondly, as this is my first TSR,
  1260. PV> how do I go about unloading the TSR from memory and how do I
  1261. PV> check for it's presence so I don't load multiple copies of
  1262. PV> it.
  1263.  
  1264. From the above I presume that you are not programming at a professional level.
  1265. I also assume it is not for an assignment.
  1266.  
  1267. TSRs are a highly complex subject and the answers to what you ask are also
  1268. complex and depend on many things.  Writing a TSR is easy.  Writing a TSR
  1269. that works dependably under all situations is difficult and requires some
  1270. assembler.  Far better
  1271. to buy a proffesional TSR toolkit and use that for doing the job.  That
  1272. way you can study the source and also learn a lot in the process.
  1273.  
  1274. TeeCee
  1275.  
  1276. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1277.  
  1278.  
  1279. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1280.  
  1281. Conference 4
  1282. Date       02-28-92 06:55:10
  1283. From       Trevor Carlsen
  1284. To         Jason Vaux
  1285. Subject    Re: gotoxy and things
  1286.  
  1287.  TCID:e8110e6d 5cec
  1288. JV>  Allright, I got sick and tired of constantly using
  1289. JV>  gotoxy(x,y);
  1290. JV>  Writeln(stuff);
  1291. JV>  over, and over again. ...
  1292.  
  1293. Jason if all you are looking for is the ability to position the cursor in
  1294. a single write/ln statement AND have a variable number of parameters as with
  1295. a normal write/ln statement it is very simple.  You have two ways you can
  1296. go:
  1297. 1.  Use a TFDD (Text File Device Driver).  This will give you a great deal
  1298.    of flexibility.
  1299. 2.  Use the following method...
  1300.  
  1301. Write a string function that returns a string of length zero and make that
  1302. string the first parameter of your write/ln statement.  Have that function
  1303. position the cursor.
  1304.  
  1305. eg.
  1306.  
  1307. function GotoXY(x,y: byte): string;
  1308.  begin
  1309.    GotoXY := ''; { an empty string }
  1310.    crt.gotoxy(x,y);
  1311.  end;
  1312.  
  1313. writeln(GotoXY(10,20),... etc.
  1314.  
  1315. Piece of cake :-)
  1316.  
  1317. Because TP6 has the extended syntax mode, this method can be used without
  1318. having to change any existing code.  If you don't like the duplication of
  1319. the names just alter its name to something like Go2XY.
  1320.  
  1321.  
  1322. TeeCee
  1323.  
  1324. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1325.  
  1326.  
  1327. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1328.  
  1329. Conference 4
  1330. Date       02-28-92 07:22:10
  1331. From       Trevor Carlsen
  1332. To         Mike Wilson
  1333. Subject    Changing Bits...
  1334.  
  1335.  TCID:72c38c32 5ced
  1336. MW> TYPE
  1337. MW>   MsgType = (Msg_Netmail,Msg_Echomail,Msg_Local);
  1338. MW>   MsgAttrs = Set of
  1339. MW> (M_Del,M_Transit,M_Netm,M_Priv,M_Rcvd,M_EchoTr,M_Local, M_R1);
  1340. MW>   NetAttrs = Set of
  1341. MW> (N_Kill,N_Sent,N_File,N_Crash,N_ReqRec,N_AudReq,N_RetRec, N_R2);
  1342. MW>   NameString = String[35];
  1343. MW>   SubjString = String[72];
  1344.  
  1345. MW> CONST
  1346. MW>   DefaultMsgAttr :Array[MsgType] of MsgAttrs=(          {May be
  1347. MW> modified}
  1348. MW>         [M_Transit,M_Netm],     {Netmail}
  1349. MW>         [M_EchoTr],             {Echomail}
  1350. MW>         [M_Local]);             {Local mail}
  1351. MW>   DefaultNetAttr :Array[MsgType] of NetAttrs=(
  1352. MW>         [],                     {Netmail}
  1353. MW>         [],                     {Echomail}
  1354. MW>         []);                    {Local mail}
  1355.  
  1356. MW>     Hdr.MsgAttr := Byte(DefaultMsgAttr[Typ]);
  1357. MW>     Hdr.NetAttr := Byte(DefaultNetAttr[Typ]);
  1358.  
  1359. MW> This will not update the Hdr.MsgAttr to turn bits 5 ON when it is echo
  1360.  
  1361. MW> mail. Same with netmail bits and bit 1.
  1362.  
  1363. Well I created a little stub program using your code and all works fine here.
  1364. The correct bits are being set.  Hdr.MsgAttr ends up with bits 1 and 5 when
  1365. Typ is Msg_Netmail.  There must be something else causing your problem.
  1366.  
  1367. TeeCee
  1368.  
  1369. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1370.  
  1371.  
  1372. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1373.  
  1374. Conference 4
  1375. Date       02-28-92 07:41:50
  1376. From       Trevor Carlsen
  1377. To         Daniel Ayotte
  1378. Subject    quote
  1379.  
  1380.  TCID:e8a75a4d 5cee
  1381. DA> Bye, Dan from Trois-Rivi*res...
  1382.  
  1383. DA>  * SLMR 2.1a * Error 216: Tagline out of paper
  1384.  
  1385. Please remove the hi-bit characters from your messages in future posts.
  1386. It is a Fidonet requirement that messages do not contain characters with
  1387. the hi-bit set.  It is therefore also a rule of this echo.
  1388.  
  1389. Trevor Carlsen
  1390. Moderator.
  1391.  
  1392. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1393.  
  1394.  
  1395. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1396.  
  1397. Conference 4
  1398. Date       02-28-92 05:15:50
  1399. From       Trevor Carlsen
  1400. To         Joshua K. @ 930/22
  1401. Subject    Re: TP6 is screwy! HELP!!
  1402.  
  1403.  TCID:abac00e5 5cea
  1404. JK> I've never heard of anyone having a Turbo Pascal Virus, but
  1405. JK> I do have the source code to the AIDS Virus [written
  1406. JK> originally in Turbo Pascal 3.01] if anyone wishes me to post
  1407. JK> it..
  1408.  
  1409. Anyone posting virus code in this echo will immediately be asked to go elsewhere(with no prior warning given) even if the purpose is innocent.  There are
  1410. too many people already with the capability to write these things and we
  1411. don't want to
  1412. extend that unnecessarily.
  1413.  
  1414. Trevor Carlsen
  1415. Moderator.
  1416.  
  1417. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1418.  
  1419.  
  1420. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1421.  
  1422. Conference 4
  1423. Date       02-29-92 10:09:40
  1424. From       Trevor Carlsen
  1425. To         Mitch Davis
  1426. Subject    Encrypting text
  1427.  
  1428.  TCID:583a2332 5d23
  1429. MD> Someone recently posted here some code for encrypting data, with a
  1430. MD> note that it was virtually impossible to crack if you forgot the key.
  1431.  
  1432. MD> The algorithm relied on reseeding the random number generator with a
  1433.  
  1434. MD> key.
  1435. MD> I'd like to have a shot at cracking it without the key.  (Daring!)
  1436.  
  1437. MD> If you'd care to repost the algorithm, together with a 64-character
  1438.  
  1439. MD> message, encrypted with this algorithm using ASCII characters 32 thru
  1440.  
  1441. MD> 127, I'll take up the challenge..
  1442.  
  1443. It was mine Mitch!  And I DID say it was simple! The "virtually impossible"
  1444. was meant for mere non-programming type mortals with no access to the algorithm
  1445. :-)  As it has been posted here twice recently I'll netmail it.  However
  1446. here's another
  1447. one of mine, a lot simpler :-), but I'll bet a system 9 lotto ticket on
  1448. you not being able to crack this one!
  1449.  
  1450. type
  1451.  bufftype = array[0..65519] of byte;
  1452.  
  1453. procedure EnDecode(var key,source,code; keylen,slen: word);
  1454.  var  x : word;
  1455.       k : bufftype absolute key;
  1456.       s : bufftype absolute source;
  1457.       c : bufftype absolute code;
  1458.  begin
  1459.    for x := 0 to slen - 1 do
  1460.      c[x] := s[x] xor k[x mod keylen];
  1461.  end;
  1462.  
  1463. Here's the hexcodes for a 64 character string.  Go to it...
  1464.  
  1465. 36  1B  0B  0C  2B  01  01  52  0C  53  65  0F  64  09  02  1D
  1466. 03  00  08  1F  0F  06  45  19  0B  18  58  1A  00  1B  13  0F
  1467. 45  42  06  1B  13  0A  49  4B  4B  0A  1F  4C  01  0B  48  1A
  1468. 0F  04  1A  5F  44  57  1C  0B  17  46  4B  27  46  45  63  4F
  1469.  
  1470. TeeCee  <evil grin>
  1471.  
  1472.  
  1473. * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1474.  
  1475.  
  1476. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1477.  
  1478. Conference 4
  1479. Date       02-28-92 21:21:20
  1480. From       Dj Murdoch
  1481. To         Kelly Small
  1482. Subject    Re: Enhanced Readkey function
  1483.  
  1484.  DM > What does @Result represent in assembly language?  A DM > register,
  1485. a memory DM > locatin, or the stack?  Thanks for your help.
  1486. KS> Well since the calling convention of Pascal places data on the
  1487. KS> stack and returns it on the stack I would have to say that
  1488. KS> @Result is placed on the stack to satisfy Pascal's calling
  1489. KS> convention, since it represents the returning value of the
  1490. KS> function.
  1491. TP generally doesn't return values on the stack - string values are the only
  1492. exception.  Most function results are returned in the registers.  However,
  1493. functions always have a local variable to hold the result; @result is it,
  1494. and it is on the
  1495. stack.  The function epilog loads the registers from that variable.  This
  1496. can lead to some redundant code.  For example, the following:
  1497.  function sum(a,b:integer):integer;
  1498.  begin
  1499.    sum := a+b;
  1500.  end;
  1501. generates
  1502. TEST.PAS#3:    sum := a+b;
  1503. 0000:000E 8B4606          MOV     AX,[BP+06]     ; AX := a
  1504. 0000:0011 034604          ADD     AX,[BP+04]     ; AX := AX + b
  1505. 0000:0014 8946FE          MOV     [BP-02],AX     ; @result := AX
  1506. TEST.PAS#4:  end;
  1507. 0000:0017 8B46FE          MOV     AX,[BP-02]     : AX := @result
  1508. ...
  1509. * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1510.  
  1511.  
  1512. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1513.  
  1514. Conference 4
  1515. Date       02-28-92 21:35:20
  1516. From       Dj Murdoch
  1517. To         Richard Morris
  1518. Subject    Re: Ancestor VMT
  1519.  
  1520.  RM> I've been playing with loading polymorphic objects from
  1521. RM> Streams, View descendants actually.  I had thought to
  1522. RM> implement a GetDescendantOnly(TypeOf(Polymorphic Root
  1523. RM> Object)) method for a Stream Descendant to construct and
  1524. RM> retrieve an object ONLY if it is a descendant of the
  1525. RM> Object type whose VMT pointer was passed.  Unfortunately
  1526. RM> the compiler doesn't store any reference to the ancestor in the VMT.
  1527. You could do it yourself, if you can maintain the discipline.  In every object,
  1528. put in a virtual function called DescendantOf, and implement it like this:
  1529. type
  1530.  Tobj = object(Tparent)
  1531.    function DescendantOf(AType : word) : boolean; virtual;
  1532.  end;
  1533. function Tobj.DescendantOf; begin
  1534.  if Atype = typeof(self) then
  1535.    DescendantOf := true
  1536.  else
  1537.    DescendantOf := Tparent.DescendantOf(Atype); end;
  1538. (Actually, this isn't quite DescendantOf, but InstanceOrDescendantOf is getting
  1539. a bit long.)
  1540. The discipline comes in because you have to implement a new copy of this
  1541. method in every object in the hierarchy, or miss being able to test for the
  1542. types you forgot.
  1543. * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1544.  
  1545.